Wir beginnen mit der Reconnaissance, um Informationen über das Zielsystem zu sammeln. Dies umfasst das Scannen des Netzwerks und das Auflisten von Hosts, um potenzielle Angriffspunkte zu identifizieren.
ARP-Scan zeigt uns die MAC-Adresse und den Hersteller der Netzwerkkarte des Ziels. Dies kann hilfreich sein, um das Betriebssystem oder die verwendete Virtualisierungstechnologie zu bestimmen.
Der Eintrag in der /etc/hosts-Datei ermöglicht uns, das Zielsystem über den Hostnamen `djinn3.vln` anzusprechen. Dies erleichtert die weitere Analyse und das Testen.
Nmap identifiziert offene Ports und Dienste auf dem Zielsystem. Besonders interessant sind: - SSH (Port 22): Ermöglicht die sichere Fernanmeldung. - HTTP (Port 80): Ein Webserver, der möglicherweise anfällige Anwendungen hostet. - HTTP (Port 5000): Ein weiterer Webserver mit Werkzeug/Python. - Port 31337: Ein benutzerdefinierter Dienst mit Authentifizierungsaufforderung. Die Werkzeug-Version (Python 3.6.9) deutet auf veraltete Software hin, die bekannte Schwachstellen aufweisen könnte.
Nachdem wir die offenen Ports identifiziert haben, konzentrieren wir uns auf die Webserver, um weitere Informationen zu sammeln und potenzielle Schwachstellen zu finden.
Wir senden eine HEAD-Anfrage an den Webserver auf Port 80, um die Header-Informationen abzurufen. Dies gibt uns Informationen über den Server (lighttpd/1.4.45) und den Inhaltstyp (text/html).
Nikto findet auf Port 80 verschiedene potenzielle Sicherheitsprobleme: - Fehlende X-Frame-Options und X-Content-Type-Options Header: Erhöhen das Risiko von Clickjacking- und MIME-Sniffing-Angriffen. - Interessante HTTP-Methoden PTINS und PST. - Fund einer Datei `#wp-config.php#`: Dies ist höchstwahrscheinlich eine Backup-Datei, die sensible Informationen wie Datenbank-Zugangsdaten enthalten könnte.
Gobuster findet die Datei `/index.html` und das Verzeichnis `/images`.
Nach der Enumeration der Webserver untersuchen wir die gefundenen Webseiten und den Dienst auf Port 31337.
Die Webseite auf Port 80 scheint eine einfache Informationsseite zu sein.
Die Webseite auf Port 5000 ist ein Ticketing-System im Entwicklungsstadium.
Wir untersuchen den Dienst auf Port 31337.
Wir verbinden uns mit dem Dienst auf Port 31337 und melden uns mit den Anmeldedaten `guest:guest` an. Der Dienst scheint eingeschränkt zu sein und akzeptiert nur bestimmte Befehle.
Wir vermuten, dass das Ticketing-System auf Port 5000 anfällig für Server-Side Template Injection (SSTI) sein könnte. Wir versuchen, dies auszunutzen, indem wir ein neues Ticket mit einer SSTI-Payload erstellen.
Wir erstellen ein neues Ticket über die Webseite auf Port 5000 und injizieren eine SSTI-Payload im Titel und in der Beschreibung.
Wir rufen das Ticket mit der ID 3709 auf und stellen fest, dass die Payload `{{7*7}}` erfolgreich zu `49` evaluiert wurde. Dies bestätigt die SSTI-Schwachstelle.
Wir verwenden eine komplexere Payload, um den Inhalt des aktuellen Verzeichnisses aufzulisten.
Nun versuchen wir, eine Reverse-Shell über die SSTI-Schwachstelle zu erlangen.
Nachdem wir die SSTI-Schwachstelle identifiziert haben und in der Lage sind, Befehle auszuführen, versuchen wir nun eine Reverse-Shell zu etablieren, um weiteren Zugriff zu erlangen und möglicherweise unsere Privilegien zu erweitern.
Wir starten einen Netcat-Listener auf unserem Angriffssystem, um die Reverse-Shell zu empfangen.
Wir erstellen eine Reverse-Bash-Payload mit `msfvenom`.
Wir erstellen ein neues Ticket mit der Payload, um die Reverse-Shell auf das Zielsystem herunterzuladen.
Wir starten einen HTTP-Server auf unserem Angriffssystem, um die Reverse-Shell bereitzustellen.
Wir starten einen zweiten HTTP-Server auf Port 8000, um den Download der Reverse-Shell zu protokollieren.
Wir erstellen ein neues Ticket mit der Payload, um die heruntergeladene Reverse-Shell auszuführen.
Wir triggern die Ausführung der Reverse-Shell.
**Fantastisch! Die Reverse-Shell-Verbindung war erfolgreich!** Wir haben eine Shell auf dem Zielsystem als Benutzer `www-data` erhalten.
Nachdem wir eine Shell als `www-data` erhalten haben, suchen wir nach Möglichkeiten, unsere Privilegien zu erhöhen.
Wir bestätigen, dass wir als Benutzer `www-data` angemeldet sind.
Wir suchen nach SUID-Binaries, die potenziell zur Privilegienerhöhung ausgenutzt werden könnten.
Wir versuchen, die `sudo -l`-Option zu verwenden, um zu sehen, welche Befehle der Benutzer `www-data` mit Root-Rechten ausführen darf.
Wir versuchen, den Befehl `at` zu verwenden, um einen Befehl mit Root-Rechten auszuführen, aber der Benutzer `www-data` hat keine Berechtigung, `at` zu verwenden.
**Fantastisch! Der Root-Zugriff war erfolgreich!** Wir laden das PwnKit-Skript herunter und führen es aus, um Root-Rechte zu erlangen.
Wir bestätigen, dass wir jetzt Root-Rechte haben.
Der folgende Befehl zeigt, dass Root-Privilegienerlangung über den PwnKit Exploit erfolgt ist.
/ \ _ __ ___ __ _ ___(_)_ __ __ _| | | |
/ _ \ | '_ ` _ \ / _` |_ / | '_ \ / _` | | | |
/ ___ \ | | | | | (_| |/ /| | | | | (_| |_|_|_|
/_/ \_\_ | |_| |_|\__,_/___|_|_| |_|\__, (_|_|_)
|___/
djinn-3 pwned...__________________________________________________________________________
Proof: VGhhbmsgeW91IGZvciB0cnlpbmcgZGppbm4zID0K
Path: /root
Date: Mon Sep 23 19:48:59 IST 2024
Whoami: root
__________________________________________________________________________
By @0xmzfr
Special thanks to @DCAU7 for his help on Privilege escalation process
And also Thanks to my fellow teammates in @m0tl3ycr3w for betatesting! :-)
If you enjoyed this then consider donating (https://blog.mzfr.me/support/)
so I can continue to make these kind of challenges.